<!DOCTYPE HTML PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN""http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html lang="en" xml:lang="en" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<head>
<META http-equiv="Content-Type" content="text/html; charset=utf-8">
<title>Guideline: Agile Estimation</title>
<meta name="uma.type" content="Guideline">
<meta name="uma.name" content="agile_estimation">
<meta name="uma.presentationName" content="Agile Estimation">
<meta name="element_type" content="other">
<meta name="filetype" content="description">
<meta name="role" content="">
<link rel="StyleSheet" href="./../../../css/default.css" type="text/css">
<script src="./../../../scripts/ContentPageResource.js" type="text/javascript" language="JavaScript"></script><script src="./../../../scripts/ContentPageSection.js" type="text/javascript" language="JavaScript"></script><script src="./../../../scripts/ContentPageSubSection.js" type="text/javascript" language="JavaScript"></script><script src="./../../../scripts/ContentPageToolbar.js" type="text/javascript" language="JavaScript"></script><script src="./../../../scripts/contentPage.js" type="text/javascript" language="JavaScript"></script><script type="text/javascript" language="JavaScript">
					var backPath = './../../../';
					var imgPath = './../../../images/';
					var nodeInfo=null;
					contentPage.preload(imgPath, backPath, nodeInfo,  '', false, false, false);
				</script>
</head>
<body>
<div id="breadcrumbs"></div>
<table border="0" cellpadding="0" cellspacing="0" width="100%">
<tr>
<td valign="top"><a name="Top"></a>
<div id="page-guid" value="_CGHskBEdEdqY7JB6N6CW2w"></div>
<table border="0" cellspacing="0" cellpadding="0" width="100%">
<tr>
<td class="pageTitle" nowrap="true">Guideline: Agile Estimation</td><td width="100%">
<div align="right" id="contentPageToolbar"></div>
</td><td width="100%" class="expandCollapseLink" align="right"><a name="mainIndex" href="./../../../index.htm"></a><script language="JavaScript" type="text/javascript" src="./../../../scripts/treebrowser.js"></script></td>
</tr>
</table>
<table width="100%" border="0" cellpadding="0" cellspacing="0">
<tr>
<td class="pageTitleSeparator"><img src="./../../../images/shim.gif" alt="" title="" height="1"></td>
</tr>
</table>
<div class="overview">
<table width="97%" border="0" cellspacing="0" cellpadding="0">
<tr>
<td width="50"><img src="./../../../images/guidance.gif" alt="" title=""></td><td>
<table class="overviewTable" border="0" cellspacing="0" cellpadding="0">
<tr>
<td valign="top">This guideline explains the three key concepts of agile estimation and how they relate to each other. It describes agile estimation concepts of size, velocity, and effort.</td>
</tr>
</table>
</td>
</tr>
</table>
</div>
<div class="sectionHeading">Relationships</div>
<div class="sectionContent">
<table class="sectionTable" border="0" cellspacing="0" cellpadding="0">
<tr valign="top">
<th class="sectionTableHeading" scope="row">Related Elements</th><td class="sectionTableCell">
<ul>
<li>
<a href="./../../../practice.mgmt.iterative_dev.base/tasks/plan_iteration_957C90DC.html" guid="_0keUEMlgEdmt3adZL5Dmdw">Plan Iteration</a>
</li>
<li>
<a href="./../../../practice.mgmt.two_level_project_planning.base/tasks/plan_the_project_A4A80C96.html" guid="_0lC70MlgEdmt3adZL5Dmdw">Plan Project</a>
</li>
<li>
<a href="./../../../core.mgmt.common.extend_supp/workproducts/work_items_list_39D03CC8.html" guid="_rGNWsCbSEdqh1LYUOGRh2A">Work Items List</a>
</li>
</ul>
</td>
</tr>
</table>
</div>
<div class="sectionHeading">Main Description</div>
<div class="sectionContent">
<table class="sectionTable" border="0" cellspacing="0" cellpadding="0">
<tr valign="top">
<td class="sectionTableSingleCell"><h3>
    Agile Estimation
</h3>
<p>
    There are three main concepts you need to understand to do agile estimation, see [<a class="elementLinkWithUserText" href="./../../../core.default.nav_view.base/guidances/supportingmaterials/references_C6FF2A8D.html#COH05" guid="__nHToFndEd2EdJKkAyeBng">COH05</a>] for more information:
</p>
<ul>
    <li>
        <strong>Estimation of Size</strong> gives a high-level estimate for the work item, typically measured using a
        neutral unit such as points
    </li>
    <li>
        <strong>Velocity</strong> tells us how many points this project team can deliver within an iteration;
    </li>
    <li>
        <strong>Estimation of Effort</strong> translates the size (measured in points) to a detailed estimate of effort
        typically using the units of Actual Days or Actual Hours. The estimation of effort indicates how long it will take
        the team member(s) to complete the assigned work item(s).
    </li>
</ul>
<h4>
    Estimation of Size
</h4>
<p>
    <strong>Points</strong> is a relative measure that can be used for agile estimation of size.&nbsp;The team decides how
    big a point is, and based on that size, determines how many points each work item is. To make estimation go fast, use
    only full points, 1, 2, 3, 5, 8, and so on, rather than fractions of a point, such 0.25, or 1.65 points. To get
    started, look at 10 or so representative work items, give the smallest the size of one point, and then go through all
    other work items and give them a relative point estimate based on that point. Note that points are used for high-level
    estimates, so do not spend too much time on any one item. This is especially true for work items of lower priority, to
    avoid wasting effort on things that are unlikely to be addressed within the current iteration.
</p>
<p>
    A key benefit of points is that they are neutral and relative. Let's say that Ann is 3 times more productive than Jack.
    If Ann and Jack agree that work item A is worth 1 point, and they both think work item B is roughly 5 times as big,
    they can rapidly agree that work item B is worth 5 points. Ann may however think work item B can be done in 12 hours,
    while Jack thinks it can be done in 36 hours. That is fine, they may disagree about the actual effort required to do
    it, but we do not care at this point in time, we only want the team to agree on the relative size. We will later use
    Velocity to determine how much 'size', or how many points, the team can take on within an iteration.
</p>
<p>
    One project team may say that a work item of a certain size is worth 1 point. Another project team would estimate the
    same sized work item to be worth 5 points. That is fine, as long as you are consistent within the same project. Make
    sure that the entire team is involved in assessing size, or at least that the same people are involved in all your size
    estimates, to ensure consistency within your project. We will see how the concept of velocity will fix also this
    discrepancy in a point meaning different things to different project teams.
</p>
<p>
    You can also use other measures of size, where the most common alternative is Ideal Days. See for example [<a class="elementLinkWithUserText" href="./../../../core.default.nav_view.base/guidances/supportingmaterials/references_C6FF2A8D.html" guid="__nHToFndEd2EdJKkAyeBng">COH05</a>] for more information.
</p>
<h4>
    Velocity
</h4>
<p>
    Velocity is a key metric used for iteration planning. It indicates how many points are delivered upon within an
    iteration for a certain team and project. As an example, a team planned to accomplish 20 points in the first iteration.
    At the end of the iteration, they noticed that they only delivered upon 14 points, their velocity was hence 14. For the
    next iteration, they may plan for fewer points, let's say 18 points, since they think they can do a little better than
    in previous iteration. In this iteration, they delivered 17 points, giving them a velocity of 17.
</p>
<p>
    Expect the velocity to change from iteration to iteration. Some iterations go smoother than others, and points are not
    always identical in terms of effort. Some team members are more effective than others, and some problems end up being
    harder than others. Also, changes to the team structure, learning new skills, changes to the tool environment, better
    teaming, or more overhead with meetings or tasks external to the project will all impact velocity. In general, velocity
    typically increases during the project as the team builds skills and becomes more cohesive.
</p>
<p>
    Velocity compensates for differences between teams in terms of how big a point is. Let's assume that project team Alpha
    and project team Beta are equally efficient in developing software, and they run the same project in parallel. Team
    Alpha, however, assesses all work items as being worth 3 times as many points as team Beta's estimates. Team Alpha
    assesses work item A, B, C, and D to correspond to 30 points, and team Beta estimates the same work items to correspond
    to 10 points. Both teams deliver upon those 4 work items in the next iteration, giving team Alpha a velocity of 30, and
    team Beta a velocity of 10. It may sound as if team Alpha is more effective, but let's look at what happens when they
    plan the next iteration. They both want to take on work item E-H, which team Alpha has estimated to be 30 points, and
    team Beta as normal has estimated to be 1/3 as many points, or 10 points. Since a team can typically take on as many
    points as indicated by their velocity, they can both take on all of E-H. The end result is that it does not matter how
    big a point is, as long as you are consistent within your team.
</p>
<p>
    Velocity also averages out the efficiency of different team members. Let's look at an example; Let's assume that Ann
    always works 3 times as fast as Jack and Jane. Ann will perhaps deliver 9 points per iteration, and Jack and Jane 3
    points each per iteration. The velocity of that 3-person team will be 15 points. As mentioned above, Ann and Jack may
    not agree on how much effort is associated with a work item, but they can agree on how many points it is worth. Since
    the team velocity is 15, the velocity will automatically translate the point estimate to how much work can be taken on.
    As you switch team members, or as team members become more or less efficient, your velocity will change, and you can
    hence take on more or less points. This does however not require you to change the estimate of the size. The size is
    still the same, and the velocity will help you to calculate how much size you can deliver upon with the team at hand
    for that iteration.
</p>
<h4>
    Estimation of Effort
</h4>
<p>
    Estimation of Effort translates the size (measured in points) to a detailed estimate of effort typically using the
    units of Actual Days or Actual Hours. As you plan an iteration, you will take on a work item, such as detail, design,
    implement and test a scenario, which may be sized to 5 points. Since this is still a reasonably big work item, break it
    down&nbsp;into a number of smaller work items, such as 4 separate work items for Detailing, Designing, Implementing and
    Testing Server portion, and Implementing and Testing Client portion of the scenario. Team members are asked to sign up
    for the tasks, and then detail the&nbsp;estimate of the actual effort, measured in hours or days, for their tasks. In
    this case, the following actual estimates were done (with person responsible within parenthesis):
</p>
<ul>
    <li>
        Detailing scenario (Ann): 4 hours
    </li>
    <li>
        Designing scenario (Ann and Jack):&nbsp; 6 hours
    </li>
    <li>
        Implementing and Testing Server portion of scenario (Jack): 22 hours&nbsp;
    </li>
    <li>
        Implementing and Testing Client portion of scenario (Ann): 12 hours
    </li>
    <li>
        <strong>Total Effort Estimate for Scenario:</strong> 44 hours
    </li>
</ul>
<p>
    If other people would be assigned to the tasks, the estimated actual hours could be quite different. There is hence no
    point doing detailed estimates until you know who will do the work, and what actual problems you will run into. Often,
    some level of analysis and design of the work item needs to take place before a reasonable estimate can be done.
    Remember that estimates are still estimates, and a person assigned to a task should feel free (and be encouraged) to
    re-estimate the effort required to complete the task, so we have a realistic view of progress within an iteration.
</p></td>
</tr>
</table>
</div>
<table class="copyright" border="0" cellspacing="0" cellpadding="0">
<tr>
<td class="copyright"><p> This program and the accompanying materials are made available under the<br />
  <a href="http://www.eclipse.org/org/documents/epl-v10.php" target="_blank">Eclipse 
  Public License V1.0</a>, which accompanies this distribution. </p><p/><p> <a class="elementLink" href="./../../../core.default.release_copyright.base/guidances/supportingmaterials/openup_copyright_C3031062.html" guid="_UaGfECcTEduSX6N2jUafGA">OpenUP Copyright</a></p></td>
</tr>
</table>
</td>
</tr>
</table>
</body>
<script type="text/javascript" language="JavaScript">
				contentPage.onload();
			</script>
</html>
